Users typically utilize many different online applications (e.g., hosted applications), each of which typically requires the user to sign on separately. For example, the ORACLE Corporation provides many different online applications such as ORACLE Financials, ORACLE HRMS, ORACLE Projects, ORACLE CRM, ORACLE PO, ORACLE Office, ORACLE Media Server, ORACLE ConText, etc. A user of some or all of these ORACLE application might additionally use online applications from other companies, such as, for example, SEIBEL, MICROSOFT, etc. The same user might additionally use one or more “home grown” or customized enterprise level applications.
Signing on to multiple applications separately is burdensome to the user, as the user must memorize and enter credentials to sign on to each application. Signing on to multiple applications separately also creates security vulnerabilities, as the credentials must be maintained by the user, who might not manage them as per proper security protocol (e.g., the user might share them, write them down, etc). Additionally, each time sign on credentials are submitted to an online application, there is a risk that the credentials could be intercepted by a malicious third party or otherwise compromised. Some issues of this nature can be addressed by single sign on (SSO) methodologies, some examples of which are described in the Parent and Provisional Applications.
Contemporary SSO techniques utilize secure identity providers. An identity provider, sometimes called an identity service provider or identity assertion provider, is an online service or website that authenticates users by means of security tokens (sometimes called identity tokens, authentication tokens or software tokens). In some cases, a service provider also operates as an identity provider. Typically, robust industry standard authentication technologies such as Security Assertion Markup Language (“SAML”) and OAuth are used in this context. However, there are a lot of installations of legacy applications such as ORACLE Application 11i that do not support SSO integration via SAML or OAuth. Conventionally, integrators and developers have been forced to either make non-supported customizations to such applications, or procure commercial solutions other than the current industry standards (e.g., SAML and OAuth) to work with the legacy applications.
It would be desirable to address these issues.